Populating a second cache with tracks from a first cache when transferring management of the tracks from a first node to a second node

ABSTRACT

Provided are a computer program product, system, and method for populating a second cache with tracks from a first cache when transferring management of the tracks from a first node to a second node. Management of a first group of tracks in the storage managed by the first node is transferred to the second node managing access to a second group of tracks in the storage. After the transferring the management of the tracks, the second node manages access to the first and second groups of tracks and caches accessed tracks from the first and second groups in the second cache of the second node. The second cache of the second node is populated with the tracks in a first cache of the first node.

BACKGROUND OF THE INVENTION 1. Field of the Invention

The present invention relates to a computer program product, system, andmethod for populating a second cache with tracks from a first cache whentransferring management of the tracks from a first node to a secondnode.

2. Description of the Related Art

In a storage controller managing access to storage volumes havingmultiple redundant nodes, during normal operation when both nodes areavailable, the nodes may split the management of volumes and tracks inthe storage. When one node is taken offline as a result of a failure orto perform a code load update, the surviving node may take overmanagement of the volumes assigned to the node taken offline to allowcontinual availability of access to all the volumes in the storage.

There is a need in the art for improved techniques for transferringownership of tracks and volumes from one node to another when suchoperations typically occur, such as during a code load update.

SUMMARY

Provided are a computer program product, system, and method forpopulating a second cache with tracks from a first cache whentransferring management of the tracks from a first node to a secondnode. Management of a first group of tracks in the storage managed bythe first node is transferred to the second node managing access to asecond group of tracks in the storage. After the transferring themanagement of the tracks, the second node manages access to the firstand second groups of tracks and caches accessed tracks from the firstand second groups in the second cache of the second node. The secondcache of the second node is populated with the tracks in a first cacheof the first node

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an embodiment of a storage environment.

FIG. 2 illustrates an embodiment of operations to transfer management oftracks in specified volumes from a source node to a target node.

FIGS. 3, 4 a, and 4 b illustrate embodiments of operations to populate atarget cache with tracks in a source cache when transferring managementof specified volumes from a source node to a target node.

FIG. 5 illustrates an embodiment of operations to perform a code loadupdate at first and second nodes.

FIG. 6 illustrates an embodiment of a computer architecture used withdescribed embodiments.

DETAILED DESCRIPTION

In prior art storage controller systems having multiple nodes, when onenode is taken offline and the volumes assigned to the surviving node,the surviving node cache does not include the content of the cache beingtaken offline, so the cache hit ratio and cache performance at thesurviving node does not match the performance when both nodes wereoperational. Described embodiments address this problem by providingtechniques to populate the cache at the surviving node with the contentof the cache at the node being taken offline so that the cache hit ratioand cache performance at the surviving node approximates the performanceexperienced when both nodes were caching data.

FIG. 1 illustrates a storage environment having a storage controller 100that provides host 102 systems access to a storage 104 over a network106. The storage controller 100 includes redundant storage nodes 108 a,108 b, where each storage node 108 a, 108 b includes a processor 110 a,110 b, comprising one or more processor devices, and a memory 112 a, 112b. Each memory 112 a, 112 b includes a storage manager 115 a, 115 b tomanage read and write access for that storage node 108 a, 108 b tovolumes 114 in the storage 104 assigned to the particular storage node108 a, 108 b. A volume 114 may comprise a Logical Unit Number (LUN),Logical Subsystem (LSS), or any grouping of tracks, where a track maycomprise a block, track or any data unit. During operations while thestorage nodes 108 a, 108 b are both operational, each storage node 108a, 108 b may be assigned to manage a specific groups of volumes 114 a,114 b, respectively.

The memories 112 a, 112 b further include a cache 116 a, 116 b,respectively, to cache read and write data with respect to the group ofvolumes 114 assigned to the storage node 108 a, 108 b having the cache116 a, 116 b. The storage manager 115 a, 115 b maintains a LeastRecently Used (LRU) list 118 a, 118 b providing an ordered index to thetracks in the cache 116 a, 116 b subject to read and write access, wherea track subject to a read or write operation is added to a Most RecentlyUsed (MRU) end of the LRU list 118 a, 118 b. The storage managers 115 a,115 b may build cache transfer lists 120 a, 120 b indicating tracks inthe cache 116 a, 116 b that need to be populated in the other cache 116b, 116 a.

The storage controller 100 may include a management console 122 coupledto the storage nodes 108 a, 108 b which includes a code load manager 124to manage a code load update to upload code, such as software andfirmware, at the storage nodes 108 a, 108 b, such as code to update thestorage managers 115 a, 115 b. In further embodiments, the managementconsole 122 may be external to the storage controller 100 andcommunicate with the storage nodes 108 a, 108 b over network 106. Instill further embodiments, the code load manager 124 may be implementedon the storage nodes 108 a, 108 b to internally manage the updating ofthe code.

The storage nodes 108 a, 108 b may communicate over a communication link126, such as a cable, bus, etc., to coordinate the transfer ofmanagement of volumes and the contents of the cache 116 a, 116 b in theevent one of the storage nodes 108 a, 108 is taken offline.

The network 106 may comprise a Storage Area Network (SAN), Wide AreaNetwork (WAN), Local Area Network (LAN), the Internet, and Intranet, awireless network, wired network, etc.

The storage 104 may comprise different types or classes of storagedevices, such as magnetic hard disk drives, solid state storage device(SSD) comprised of solid state electronics, EEPROM (ElectricallyErasable Programmable Read-Only Memory), flash memory, flash disk,Random Access Memory (RAM) drive, storage-class memory (SCM), etc.,Phase Change Memory (PCM), resistive random access memory (RRAIVI), spintransfer torque memory (STM-RAM), conductive bridging RAM (CBRAM),magnetic hard disk drive, optical disk, tape, etc. The volumes 114 mayfurther be configured from an array of devices, such as Just a Bunch ofDisks (JBOD), Direct Access Storage Device (DASD), Redundant Array ofIndependent Disks (RAID) array, virtualization device, etc. Further, thestorage 104 may comprise heterogeneous storage devices from differentvendors and different types of storage devices, such as a first type ofstorage devices, e.g., hard disk drives, that have a slower datatransfer rate than a second type of storage devices, e.g., SSDs.

In certain embodiments, one or more volumes 114 may be implemented indifferent types of storage devices. For instance, some of the tracks ofone or more volumes 114 may be configured in hard disk drives, whileother of the tracks of one or more volumes 114 may be configured inSSDs. Thus, a first type of storage device in which volumes 114 areconfigured may have a slower data access and transfer rate than a secondtype of storage device in which volumes are configured.

FIGS. 2 and 3 illustrate an embodiment of operations to transferownership of specified volumes, e.g., groups of volumes 114 a and/or 114b, and tracks in the cache from a source node (e.g., node 108 a or 108b) to a target node (e.g., node 108 b or 108 a). The source node is thesource of the transfer and the target node is the target of the transferof the management of specified volumes, and either nodes 108 a, 108 bmay be the source or the target. The operations of FIGS. 2 and 3 may beperformed by the node storage managers 115 a, 115 b and/or the code loadmanager 124 or other component, such as a failback and failover manager.With respect to FIG. 2, upon initiating (at block 200) the operation totransfer ownership of the specified volumes, such as groups of volumes114 a and/or 114 b, I/O access at the source node may be quiesced (atblock 202). The source node may then destage (at block 204) updates totracks in the specified volumes in the source cache, e.g., 116 a, 116 b,to the volumes 114 in the storage 104. The source storage manager, e.g.,115 a or 115 b, may then transfer (at block 206) management, such asownership, of the specified volumes assigned to the source node to thetarget node, so that the target node will handle I/O access to thetransferred group of volumes 114 previously assigned to the source node.

I/O quiesced on the source node may then be resumed (at block 208) onthe target node for the specified volumes. At this point, the sourcenode may be taken off line for code load update, repairs, upgrades, etc.

The source storage manager may build (at block 210) a source cachetransfer list, e.g., 120 a or 120 b, of tracks in the source cachestarting from the MRU end of the LRU list 118 a until a maximum numberof tracks are added to the source cache transfer list. The source cachetransfer list is then sent (at block 212) to the target node.

FIG. 3 illustrates an embodiment of operations performed by the targetstorage manager, e.g., 115 a or 115 b, at the target node to populatethe target cache with the content of the source cache at the time whenmanagement of the specified volumes was transferred. Upon the targetnode receiving (at block 300) the source cache transfer list from thesource node, the target storage manager performs a loop of operations302-312 for each sequence of N tracks in the source cache transfer listto process the indicated tracks in groups of N. The N tracks beingconsidered are accessed (at block 304) to prevent access by anotherprocess. Access is released (at block 306) for any of the accessedtracks that are already in the target cache 116 b. The target storagemanager or other component then populates the target cache with theaccessed N tracks in the source cache. The target cache may be populatedwith the accessed of the N tracks by transferring the accessed of the Ntracks from the source cache directly to the target cache, such asthrough a Direct Memory Access (DMA) operation, or the tracks may beread from the storage 104 and cached in the target cache. After targetcache is populated with the N of the tracks from the source cache,access to the tracks is released (at block 310). Control proceeds (atblock 312) back to block 302 to consider a next N (or remaining) tracksin the source cache until all the tracks in the source cache transferlist are processed.

In the operations of FIGS. 2 and 3, the transfer of management of thespecified volumes and the population of tracks in the target cache areperformed with respect to specified volumes. In alternative embodiments,groupings of tracks and data units other than volumes may be specifiedfor the transfer of tracks and population of the target cache.

With the operations of FIGS. 2 and 3, the target cache of the targetnode is populated with the tracks in the source cache from which volumemanagement is transferred to maintain the cache hit ratio of cacheaccess during the time the source node is not servicing host I/Orequests, because the target cache is populated with the tracks in thesource cache to maintain the cache hit ratio at the target node to whichmanagement of the volumes is transferred.

FIGS. 4a and 4b illustrate an alternative embodiment of operations topopulate the target cache, e.g., 116 a or 116 b, with tracks forspecified volumes, e.g., groups of volumes 114 a and/or 114 b, in thesource cache, e.g., 116 a or 116 b, that takes into account the transferrate speed of the type of storage device in which the tracks are stored.In the operations of FIG. 4a , the source node would have generated asource cache transfer list 120 a having tracks in the source LRU list118 a or 118 b that are in a first type of storage device, e.g., arelatively slower transfer rate storage such as a hard disk drive. Uponthe target node, e.g., 108 a or 108 b, receiving (at block 400) thesource cache transfer list, e.g., 120 a, 120 b, of tracks for a firsttype of storage device having relatively slower data transfer rate(e.g., hard disk drive), the target storage manager performs a loop ofoperations at blocks 402 through 412 for each sequence of N tracks inthe source cache transfer list to process the indicated tracks in groupsof N. The N tracks being considered are accessed (at block 404) toprevent access by another process. Access is released (at block 406) forany of the accessed tracks that are already in the target cache 116 b.The target storage manager or other component causes the transfer of theaccessed N tracks in the source cache directly to the target cache fromthe source cache over the link 126, such as by using a DMA operationfrom the source cache to the target cache. After the tracks aretransferred, access to the tracks is released (at block 410). Controlproceeds (at block 412) to block 402 to consider a next N (or remaining)tracks in the source cache transfer list until all the tracks in thesource cache transfer list are processed.

In the operations of FIG. 4b , the source node would have generated asource cache transfer list, e.g., 120 a, 120 b, having tracks in thesource LRU list 118 a or 118 b that are in a second type of storagedevice, such as having a faster transfer rate, such as a SSD, which isfaster than the first type of storage device. Upon the target node,e.g., 108 a or 108 b, receiving (at block 414) the source cache transferlist, e.g., 120 a, 120 b of tracks for a second type of storage devicehaving a faster data transfer rate (e.g., SSD), the target storagemanager performs a loop of operations at blocks 416 through 434 for eachsequence of N+M tracks in the source cache transfer list to process theindicated tracks in groups of N+M tracks in the faster second type ofstorage device. The target storage manager then performs two streams ofparallel operations, a first stream at blocks 418 through 424 for thefirst N tracks and a second stream at block 426 through 432 for thesecond M tracks in the group of N+M tracks.

For the first stream, the target storage manager accesses (at block 418)the N tracks to prevent access by another process. Access is released(at block 420) for any of the accessed N tracks that are already in thetarget cache already. The target storage manager or other componentcauses (at block 422) the transfer of the accessed N tracks in thesource cache directly to the target cache from the source cache, such asby using a DMA operation from the source cache to the target cache.After the tracks are transferred, access to the tracks is released (atblock 424).

For the second stream and in parallel to the operations performed forthe first stream, the target storage manager accesses (at block 426) theM tracks following the N tracks in the source cache transfer list in thegroup of N+M tracks to prevent access by another process. Access isreleased (at block 428) for any of the accessed M tracks that arealready in the target cache already. The target storage manager or othercomponent reads (at block 430) the accessed of the M tracks that are inthe source cache from the second type of storage device, such as an SSD.After the tracks are transferred, access to the tracks is released (atblock 432).

After performing both parallel streams of transferring the N and Mtracks, control proceeds (at block 434) to block 416 to consider a nextN+M (or remaining) tracks in the source cache transfer list until allthe tracks in the source cache transfer list are processed.

In the operations of FIG. 4b , N and M may be set such that bothseparate streams of cache transfer operations, through DMA from thesource cache or reading from storage, would complete at approximatelythe same time. For instance, if the DMA operations are faster than thereading from the fast access storage device, e.g., SSD, then N may beset to a greater number than M so that both the first and second streamsof transfer operations complete at approximately the same time. Theopposite is true, i.e., M is greater than N, if the storage device readoperations have a faster transfer time than the cache DMA operation.

With the operations of FIG. 4b , if the tracks are stored in a fasteraccess storage device, then the tracks in the source cache may betransferred from two different locations, a direct DMA transfer from thesource cache and from the faster access storage devices to reduce thetime needed to populate the target cache with the tracks from the sourcecache by transferring tracks in parallel from two different datasources. When the storage devices in which the tracks are stored are notsufficiently fast to approximate the speed of the DMA transfer, then asin FIG. 4a , all the tracks may be transferred directly from the sourcecache.

In a still further embodiment, the tracks can be transferred in paralleldirectly from the source cache for tracks stored in the slower firsttype of storage device and at the same time tracks in the second type ofstorage device can be read from the faster storage device.

In implementations where the storage 104 is only comprised of the firsttype of storage devices, then only the operations at blocks 402-412 inFIG. 4a would be performed to populate the target cache with the tracksin the source. In implementation where the storage 104 is only comprisedof the second type of storage devices, then only the operations atblocks 416-434 would be performed to populate the target cache with thetracks in the source cache.

FIG. 5 illustrates an embodiment of operations to use the volumemanagement transfer and cache transfer operations of FIGS. 2, 3, 4 a,and 4 b in the context of performing a code load operation at the first108 a and second 108 b nodes of a storage controller 100 to allow one ofthe nodes 108 a or 108 b to remain online servicing I/O requestsdirected to the volumes 114 while the other of the nodes 108 b or 108 ais having a code load update. Upon initiating (at block 500) code loadoperations, the code load manager 124 may initiate the operations ofFIGS. 2 and 3 (or alternately FIGS. 4a and 4b ) to transfer managementof first group of volumes 114 a (operating as the specified volumes)from the first node 108 a (operating as the source node) to the secondnode 108 b (operating as the target node) and populate the second cache116 bf with all the tracks in first cache 116 a. After performing thetransfer, the code load at the first node 108 a is performed (at block504) to update the code at the first node 108 a. While the first node108 a is being updated, the second node 108 a may handle I/O operationsfrom the hosts 102 to the volumes 114 uninterrupted.

After completing the code load at the first node 108 a, the operationsof FIGS. 2 and 3 (or alternately FIGS. 4a and 4b ) are performed (atblock 506) to transfer management of the first 114 a and second 114 bgroups of volumes (operating as the specified volumes) from the secondnode 108 b (operating as the source node) to the first node 108 a(operating as the target node) and populate the first cache 116 a withall tracks in the second cache 116 b. After transferring the managementof the volumes to the first node 108 a, the code load at the second node108 b is performed (at block 508) to update the code at the second node108 b. While the second node 108 b is being updated during the codeload, the first node 108 a may continue servicing I/O operations fromthe hosts 102 to the volumes 114 uninterrupted.

After updating the code at both the first 108 a and the second 108 bnodes, the operations of FIGS. 2 and 3 (or alternately FIGS. 4a and 4b )are performed (at block 510) to transfer management of the second group114 b (operating as the specified volumes) from the first node 108 a(operating as the source node) back to the second node 108 b (operatingas the target node) and populate the second cache 116 b with the tracksin the second group of volumes 114 b in the first cache 116 a.

After the operations of block 510, both nodes 108 a, 108 b manage/ownthe groups of volumes 114 a, 114 b originally assigned to the nodes toreturn the controller 100 to the assignment of volumes to nodes thatexisted before the code load updates at the nodes 108 a, 108 b.

Further, with the embodiments of FIG. 5 during the code load, the cache116 a, 116 b of the surviving node is populated with the tracks in thecache of the node that will be subject to the code update to maintainthe cache hit ratio of cache access during the time one of the nodes 108a, 108 b is taken offline to perform a code load update.

Although the operations of FIGS. 2, 3, 4 a, and 4 b may be performedduring a code load update as in the described embodiment of FIG. 5, inalternative embodiments, the volume management transfer and cachetransfer operations of FIGS. 2, 3, 4 a, and 4 b may be performed inother contexts such as a failover and failback from one node to theother if one node fails. After a failed node is serviced and broughtback online, the operations at block 510 in FIG. 5 may be performed toreturn the volumes initially assigned to the failed and reassigned tothe surviving node back to the now operational node.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Java, Smalltalk, C++ or the like,and conventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

The computational components of FIG. 1, including the nodes 108 a, 108b, and hosts 102 may be implemented in one or more computer systems,such as the computer system 602 shown in FIG. 6. Computer system/server602 may be described in the general context of computer systemexecutable instructions, such as program modules, being executed by acomputer system. Generally, program modules may include routines,programs, objects, components, logic, data structures, and so on thatperform particular tasks or implement particular abstract data types.Computer system/server 602 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program modules may be locatedin both local and remote computer system storage media including memorystorage devices.

As shown in FIG. 6, the computer system/server 602 is shown in the formof a general-purpose computing device. The components of computersystem/server 602 may include, but are not limited to, one or moreprocessors or processing units 604, a system memory 606, and a bus 608that couples various system components including system memory 606 toprocessor 604. Bus 608 represents one or more of any of several types ofbus structures, including a memory bus or memory controller, aperipheral bus, an accelerated graphics port, and a processor or localbus using any of a variety of bus architectures. By way of example, andnot limitation, such architectures include Industry StandardArchitecture (ISA) bus, Micro Channel Architecture (MCA) bus, EnhancedISA (EISA) bus, Video Electronics Standards Association (VESA) localbus, and Peripheral Component Interconnects (PCI) bus.

Computer system/server 602 typically includes a variety of computersystem readable media. Such media may be any available media that isaccessible by computer system/server 602, and it includes both volatileand non-volatile media, removable and non-removable media.

System memory 606 can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 610 and/or cachememory 612. Computer system/server 602 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 613 can be provided forreading from and writing to a non-removable, non-volatile magnetic media(not shown and typically called a “hard drive”). Although not shown, amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and an optical diskdrive for reading from or writing to a removable, non-volatile opticaldisk such as a CD-ROM, DVD-ROM or other optical media can be provided.In such instances, each can be connected to bus 908 by one or more datamedia interfaces. As will be further depicted and described below,memory 606 may include at least one program product having a set (e.g.,at least one) of program modules that are configured to carry out thefunctions of embodiments of the invention.

Program/utility 614, having a set (at least one) of program modules 616,may be stored in memory 606 by way of example, and not limitation, aswell as an operating system, one or more application programs, otherprogram modules, and program data. Each of the operating system, one ormore application programs, other program modules, and program data orsome combination thereof, may include an implementation of a networkingenvironment. The components of the computer 602 may be implemented asprogram modules 616 which generally carry out the functions and/ormethodologies of embodiments of the invention as described herein. Thesystems of FIG. 1 may be implemented in one or more computer systems602, where if they are implemented in multiple computer systems 602,then the computer systems may communicate over a network.

Computer system/server 602 may also communicate with one or moreexternal devices 618 such as a keyboard, a pointing device, a display620, etc.; one or more devices that enable a user to interact withcomputer system/server 602; and/or any devices (e.g., network card,modem, etc.) that enable computer system/server 602 to communicate withone or more other computing devices. Such communication can occur viaInput/Output (I/O) interfaces 622. Still yet, computer system/server 602can communicate with one or more networks such as a local area network(LAN), a general wide area network (WAN), and/or a public network (e.g.,the Internet) via network adapter 624. As depicted, network adapter 624communicates with the other components of computer system/server 602 viabus 608. It should be understood that although not shown, other hardwareand/or software components could be used in conjunction with computersystem/server 602. Examples, include, but are not limited to: microcode,device drivers, redundant processing units, external disk drive arrays,RAID systems, tape drives, and data archival storage systems, etc.

The terms “an embodiment”, “embodiment”, “embodiments”, “theembodiment”, “the embodiments”, “one or more embodiments”, “someembodiments”, and “one embodiment” mean “one or more (but not all)embodiments of the present invention(s)” unless expressly specifiedotherwise.

The terms “including”, “comprising”, “having” and variations thereofmean “including but not limited to”, unless expressly specifiedotherwise.

The enumerated listing of items does not imply that any or all of theitems are mutually exclusive, unless expressly specified otherwise.

The terms “a”, “an” and “the” mean “one or more”, unless expresslyspecified otherwise.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or moreintermediaries.

A description of an embodiment with several components in communicationwith each other does not imply that all such components are required. Onthe contrary a variety of optional components are described toillustrate the wide variety of possible embodiments of the presentinvention.

When a single device or article is described herein, it will be readilyapparent that more than one device/article (whether or not theycooperate) may be used in place of a single device/article. Similarly,where more than one device or article is described herein (whether ornot they cooperate), it will be readily apparent that a singledevice/article may be used in place of the more than one device orarticle or a different number of devices/articles may be used instead ofthe shown number of devices or programs. The functionality and/or thefeatures of a device may be alternatively embodied by one or more otherdevices which are not explicitly described as having suchfunctionality/features. Thus, other embodiments of the present inventionneed not include the device itself.

The foregoing description of various embodiments of the invention hasbeen presented for the purposes of illustration and description. It isnot intended to be exhaustive or to limit the invention to the preciseform disclosed. Many modifications and variations are possible in lightof the above teaching. It is intended that the scope of the invention belimited not by this detailed description, but rather by the claimsappended hereto. The above specification, examples and data provide acomplete description of the manufacture and use of the composition ofthe invention. Since many embodiments of the invention can be madewithout departing from the spirit and scope of the invention, theinvention resides in the claims herein after appended.

What is claimed is:
 1. A computer program product for transferringtracks from a first node having a first cache to a second node having asecond cache, the computer program product comprising a computerreadable storage medium having computer readable program code embodiedtherein that is executable to perform operations, the operationscomprising: providing a cache transfer list of tracks in the first cacheto transfer to the second cache to manage by the second node;transferring a first number of tracks indicated in the cache transferlist maintained in the first cache from the first cache to the secondcache; and transferring a second number of tracks indicated in the cachetransfer list maintained in the first cache and stored in a storage fromthe storage to the second cache.
 2. The computer program product ofclaim 1, wherein the operations further comprise: managing, by thesecond node, access to the tracks in the cache transfer list aftertransferring the tracks from the first cache to the second cache.
 3. Thecomputer program product of claim 1, wherein the transferring of thefirst number of tracks from the first cache and the transferring of thesecond number of tracks from the storage are performed in parallel. 4.The computer program product of claim 1, wherein the storage comprises afirst type of storage, wherein the first number of tracks transferredfrom the first cache are stored in a second type of storage, wherein thefirst type of storage has a faster access than the second type ofstorage.
 5. The computer program product of claim 1, wherein the secondnumber of tracks follows the first number of tracks in the cachetransfer list.
 6. The computer program product of claim 1, whereinmultiple iterations of transferring the first number of tracks andtransferring the second number of tracks are performed until all tracksindicated in the cache transfer list are transferred to the secondcache.
 7. The computer program product of claim 1, wherein thetransferring of the first number of tracks comprises accessing tracks ofthe first number of tracks that are not currently stored in the secondcache and releasing the accessed tracks of the first number of tracks inresponse to transferring the first number of tracks to the second cache,and wherein the transferring of the second number of tracks comprisesaccessing tracks of the second number of tracks that are not currentlystored in the second cache and releasing the accessed tracks of thesecond number of tracks in response to transferring the second number oftracks to the second cache.
 8. A system for transferring tracks from afirst node having a first cache comprising: a processor; a second cache;a computer readable storage medium having computer readable program codeembodied therein that is executable to perform operations, theoperations comprising: receiving a cache transfer list of tracks in thefirst cache to transfer to the second cache to manage by the system;transferring a first number of tracks indicated in the cache transferlist maintained in the first cache from the first cache directly to thesecond cache; and transferring a second number of tracks indicated inthe cache transfer list maintained in the first cache and stored in astorage from the storage to the second cache.
 9. The system of claim 8,wherein the operations further comprise: managing access to the tracksin the cache transfer list after transferring the tracks from the firstcache to the second cache.
 10. The system of claim 8, wherein thetransferring of the first number of tracks from the first cache and thetransferring of the second number of tracks from the storage areperformed in parallel.
 11. The system of claim 8, wherein the storagecomprises a first type of storage, wherein the first number of trackstransferred from the first cache are stored in a second type of storage,wherein the first type of storage has a faster access than the secondtype of storage.
 12. The system of claim 8, wherein the second number oftracks follows the first number of tracks in the cache transfer list.13. The system of claim 8, wherein multiple iterations of transferringthe first number of tracks and transferring the second number of tracksare performed until all tracks indicated in the cache transfer list aretransferred to the second cache.
 14. The system of claim 8, wherein thetransferring of the first number of tracks comprises accessing tracks ofthe first number of tracks that are not currently stored in the secondcache and releasing the accessed tracks of the first number of tracks inresponse to transferring the first number of tracks to the second cache,and wherein the transferring of the second number of tracks comprisesaccessing tracks of the second number of tracks that are not currentlystored in the second cache and releasing the accessed tracks of thesecond number of tracks in response to transferring the second number oftracks to the second cache.
 15. A method for transferring tracks from afirst node having a first cache to a second node having a second cache,comprising: providing a cache transfer list of tracks in the first cacheto transfer to the second cache to manage by the second node;transferring a first number of tracks indicated in the cache transferlist maintained in the first cache from the first cache to the secondcache; and transferring a second number of tracks indicated in the cachetransfer list maintained in the first cache and stored in a storage fromthe storage to the second cache.
 16. The method of claim 15, furthercomprising: managing, by the second node, access to the tracks in thecache transfer list after transferring the tracks from the first cacheto the second cache.
 17. The method of claim 15, wherein thetransferring of the first number of tracks from the first cache and thetransferring of the second number of tracks from the storage areperformed in parallel.
 18. The method of claim 15, wherein the storagecomprises a first type of storage, wherein the first number of trackstransferred from the first cache are stored in a second type of storage,wherein the first type of storage has a faster access than the secondtype of storage.
 19. The method of claim 15, wherein the second numberof tracks follows the first number of tracks in the cache transfer list.20. The method of claim 15, wherein multiple iterations of transferringthe first number of tracks and transferring the second number of tracksare performed until all tracks indicated in the cache transfer list aretransferred to the second cache.
 21. The method of claim 15, wherein thetransferring of the first number of tracks comprises accessing tracks ofthe first number of tracks that are not currently stored in the secondcache and releasing the accessed tracks of the first number of tracks inresponse to transferring the first number of tracks to the second cache,and wherein the transferring of the second number of tracks comprisesaccessing tracks of the second number of tracks that are not currentlystored in the second cache and releasing the accessed tracks of thesecond number of tracks in response to transferring the second number oftracks to the second cache.